Client/server architecture involves a lower performance and less expensive client device (typically) located on an employee's desktop, such as a personal computer (PC), communicatively coupled through a local area network (LAN), corporate intranet, the Internet or other network to a higher performance and more expensive server device, such as a workstation or mainframe.
The benefit of the client/server architecture is overall reduced cost per MIPS due to the implementation of the inexpensive desktop devices. Generally, sophisticated tasks are left to the server while more mundane tasks are left to the client resulting in better cost performance as compared to other architectures (such as purely terminal based environments).
As such, application programs running over the client/server architecture involve cooperative software located on both the client and the server. Two approaches have generally been taken to divide the functional responsibility between the server software and the client software: the traditional client server approach 101, shown in FIG. 1a, and the display oriented approach 102, shown in FIG. 1b. 
The traditional approach 101 involves client software 103 executed on the client 107a that translates between GUI interactivity 104a with the client's graphical user interface (GUI) 105a and function calls/responses 106 issued to/from the server software 108a. In this approach, the client software 103 manages significant application logic while leaving sophisticated or necessarily centralized functionality for the server software 108a. 
The display oriented approach 102, sends all GUI interactivity 104b over the network. As such the client software is practically non existent since the GUI itself 105b represents the most substantial logic existing on the client 107b. 
Many application software types are programmable. Programmable application software is used to create custom software routines (e.g., a custom automated inventory workflow for a specific company). Typically, the custom software routines conform to a programmable environment. A programmable environment is essentially a set of global programming rules capable of supporting different custom software routines.
Unfortunately, both of the aforementioned approaches 101, 102 do not handle programmable environments well. As for the traditional approach 101, the main problems derive from the client software's 103 attempt to support the full range of behavior allowed by a comprehensive programmable environment. A first issue concerns efficiency. That is, the client software 103 must be able to successfully handle all types of user activity even if many forms are simply never utilized. For example, if a specific programmable application happens to use only ten programmable operations out of a possible 300, its associated client software 103 must contain logic to handle all 300 possible actions.
A second issue concerns the client software's 103 “awareness”. For example, consider an instance where a programmable environment rule mandates initiation of a data entry form when both a certain button is clicked and a certain field has the value “X”. The client software 103 intelligence should recognize whether the field has the value “X” when the button is clicked before sending a “data entry form” request to the server software 108a. As such, the client software 103 must have sufficient awareness as to the applicable programming rules.
Another problem involves download time. When the application is commenced, the large and complicated blocks of client software 103 consume too much time when downloaded from the server. Thus, in the traditional approach 101, large and complex client software 103 frequently presents too much offered load to the client device during application operation and to the network during application initiation. Furthermore, pre-installation of large client software 103 modules on the client machine 107a increase the cost of maintaining such installations and the pre-installation requirements can render the applications unusable in environments such as the World Wide Web.
The display oriented approach 102 of FIG. 1b fairly addresses the above problems. Essentially, most of the logic associated with the client software 103 of the traditional approach 101 is transferred to the server software 108b. Since the remaining client software is negligible there is little offered load to the client device 107b. 
However, under the display oriented approach 102, the application typically assumes some standard display mechanism exists. The server software 108b is therefore locked into a single set of display characteristics and capabilities. For example HTML takes away a significant amount of programmer control over display since the layout is done using the constraint based mechanisms of HTML. This constraint is prohibitive in programmable environments which typically require an ability to create various display features.
Thus, for programmable environments, the traditional approach 101 comprises too much client software 103 while the display approach limits 102 the application (or at least the server software 108b) to a single set of display mechanisms.
What is needed is a new approach suitable for programmable environments.